Skip to content

Make TypeId const comparable #142789

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 18 commits into
base: master
Choose a base branch
from
Open

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Jun 20, 2025

This should unblock stabilizing const TypeId::of and allow us to progress into any possible future we want to take TypeId to.

To achieve that TypeId now contains 16 / size_of<usize>() pointers which each are actually just size_of<usize>() bytes of the stable hash. At compile-time the first of these pointers cannot be dereferenced or otherwise inspected (at present doing so might ICE the compiler). Preventing inspection of this data allows us to refactor TypeId to any other scheme in the future without breaking anyone who was tempted to transmute TypeId to obtain the hash at compile-time.

cc @eddyb for their previous work on #95845 (which we still can do in the future if we want to get rid of the hash as the final thing that declares two TypeIds as equal).

r? @RalfJung

@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 20, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jun 20, 2025

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

@rust-log-analyzer

This comment has been minimized.

@oli-obk oli-obk force-pushed the constable-type-id branch from 3cddd21 to 1fd7b66 Compare June 21, 2025 10:20
@rust-log-analyzer

This comment has been minimized.

@RalfJung
Copy link
Member

It will be a while until I have the capacity to review a PR of this scale.

Meanwhile, could you say a bit more about the architecture of the change? It seems you want for the "new kind of allocation" approach, but it's not clear from the PR description how exactly that shows up in TypeId.

Also, I am definitely not comfortable landing this by myself, I can only review the const-eval parts. Changing the representation of TypeId has ramifications well beyond that that I do not feel qualified to evaluate -- I think an MCP would be justified.

@rustbot
Copy link
Collaborator

rustbot commented Jun 21, 2025

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

@oli-obk
Copy link
Contributor Author

oli-obk commented Jun 21, 2025

Well, I got private feedback yesterday that instead of encoding a 16 byte value as an 8 byte pointer to the 16 byte value and an 8 byte hash, I should just do the thing where we split up type id internally into pointer sized chunks and codegen will make a hash out of it again.

TLDR: no changes to runtime type id anymore in the latest revision of this PR. Only compile-time type id is now a bit funny

@oli-obk
Copy link
Contributor Author

oli-obk commented Jun 21, 2025

It will be a while until I have the capacity to review a PR of this scale.

I'm splitting unrelated parts out, so the high level feedback is already useful and I'll look for libs and codegen ppl to review the appropriate parts

@rust-log-analyzer

This comment has been minimized.

jdonszelmann added a commit to jdonszelmann/rust that referenced this pull request Jun 23, 2025
Make `PartialEq` a `const_trait`

r? `@fee1-dead` or `@compiler-errors`

something generally useful but also required for rust-lang#142789
jdonszelmann added a commit to jdonszelmann/rust that referenced this pull request Jun 23, 2025
Make `PartialEq` a `const_trait`

r? ``@fee1-dead`` or ``@compiler-errors``

something generally useful but also required for rust-lang#142789
rust-timer added a commit that referenced this pull request Jun 23, 2025
Rollup merge of #142822 - oli-obk:const-partial-eq, r=fee1-dead

Make `PartialEq` a `const_trait`

r? ``@fee1-dead`` or ``@compiler-errors``

something generally useful but also required for #142789
@bors
Copy link
Collaborator

bors commented Jun 23, 2025

☔ The latest upstream changes (presumably #142906) made this pull request unmergeable. Please resolve the merge conflicts.

@oli-obk oli-obk force-pushed the constable-type-id branch 2 times, most recently from b8a7a10 to 1c47a64 Compare June 24, 2025 09:25
@rust-log-analyzer

This comment has been minimized.

@oli-obk oli-obk force-pushed the constable-type-id branch from 1c47a64 to bcb4aa2 Compare June 24, 2025 13:02
@rust-log-analyzer

This comment has been minimized.

@rust-timer

This comment has been minimized.

rust-bors bot added a commit that referenced this pull request Jul 4, 2025
Make TypeId const comparable

This should unblock stabilizing const `TypeId::of` and allow us to progress into any possible future we want to take `TypeId` to.

To achieve that `TypeId` now contains `16 / size_of<usize>()` pointers which each are actually just `size_of<usize>()` bytes of the stable hash. At compile-time the first of these pointers cannot be dereferenced or otherwise inspected (at present doing so might ICE the compiler). Preventing inspection of this data allows us to refactor `TypeId` to any other scheme in the future without breaking anyone who was tempted to transmute `TypeId` to obtain the hash at compile-time.

cc `@eddyb` for their previous work on #95845 (which we still can do in the future if we want to get rid of the hash as the final thing that declares two TypeIds as equal).

* #77125

r? `@RalfJung`
@rust-bors
Copy link

rust-bors bot commented Jul 4, 2025

⌛ Trying commit a7888a7 with merge 448540b

To cancel the try build, run the command @bors2 try cancel.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 4, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-bors
Copy link

rust-bors bot commented Jul 4, 2025

☀️ Try build successful (CI)
Build commit: 448540b (448540b0e20d48e1a38b06460a73ebec5ee805f0, parent: 1b61d43bdbf875183b1f436302d62ff93f9a6bba)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (448540b): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
0.4% [0.4%, 0.4%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.3% [-0.4%, -0.2%] 2
Improvements ✅
(secondary)
-0.8% [-0.8%, -0.8%] 2
All ❌✅ (primary) -0.1% [-0.4%, 0.4%] 3

Max RSS (memory usage)

Results (primary 1.7%, secondary 1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
3.2% [1.7%, 4.9%] 5
Regressions ❌
(secondary)
4.0% [0.5%, 9.0%] 5
Improvements ✅
(primary)
-5.8% [-5.8%, -5.8%] 1
Improvements ✅
(secondary)
-2.3% [-3.3%, -0.4%] 4
All ❌✅ (primary) 1.7% [-5.8%, 4.9%] 6

Cycles

Results (primary 0.8%, secondary 1.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.3% [2.3%, 2.3%] 2
Regressions ❌
(secondary)
3.3% [1.4%, 4.5%] 4
Improvements ✅
(primary)
-2.3% [-2.3%, -2.3%] 1
Improvements ✅
(secondary)
-2.2% [-2.2%, -2.1%] 2
All ❌✅ (primary) 0.8% [-2.3%, 2.3%] 3

Binary size

Results (primary 0.1%, secondary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
0.1% [0.0%, 0.3%] 23
Regressions ❌
(secondary)
0.0% [0.0%, 0.0%] 1
Improvements ✅
(primary)
-0.4% [-0.5%, -0.4%] 2
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.1% [-0.5%, 0.3%] 25

Bootstrap: 462.82s -> 460.745s (-0.45%)
Artifact size: 372.13 MiB -> 372.22 MiB (0.03%)

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Jul 4, 2025
@RalfJung
Copy link
Member

RalfJung commented Jul 4, 2025

Lol, seems it speeds up more benchmarks than it slows down. ;) I assume Any isn't used that much in rustc... but if it's a problem we can always keep adjusting the representation later.

@bors
Copy link
Collaborator

bors commented Jul 4, 2025

☔ The latest upstream changes (presumably #143434) made this pull request unmergeable. Please resolve the merge conflicts.

@oli-obk
Copy link
Contributor Author

oli-obk commented Jul 4, 2025

ctfe improvements are just the opt of not creating an allocation anymore just to copy it and throw it away.

The others are llvm opt changes that are probably unrelated. This is not used enough to cause compile time changes and we have no dedicated runtime benchmarks for it

@RalfJung
Copy link
Member

RalfJung commented Jul 4, 2025

Makes sense.

There is one unresolved comment still up, and the one I just commented on.
Also, needs a rebase.
Also, this is blocked on #143444.
@rustbot author

I am not 100% confident in the GCC and cranelift changes; @bjorn3 @rust-lang/wg-gcc-backend would be good if you could take a look. This is a new "magic" kind of pointer where codegen should just ignore the AllocId and emit a regular integer with the pointer's offset.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 4, 2025
@oli-obk oli-obk force-pushed the constable-type-id branch from a7888a7 to 58d86ec Compare July 4, 2025 19:17
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 4, 2025
clean up GVN TypeId test

addresses rust-lang#142789 (comment)

This is an attempt to clarify what this test is actually supposed to test and make it less dependent on `TypeId` internals (it now depends on the output of `type_name` instead).

I verified that this version still miscompiles on `nightly-2025-02-11`.

r? `@oli-obk` `@RalfJung`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 4, 2025
clean up GVN TypeId test

addresses rust-lang#142789 (comment)

This is an attempt to clarify what this test is actually supposed to test and make it less dependent on `TypeId` internals (it now depends on the output of `type_name` instead).

I verified that this version still miscompiles on `nightly-2025-02-11`.

r? ``@oli-obk`` ``@RalfJung``
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. perf-regression Performance regression. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.